NFC is a short-range radio frequency (RF) communication technology, typically operating at a distance of 10 cm or less between two communicating devices. Communication under NFC involves an initiator device (often referred to as a “reader”) and a target device.
In a simple NFC communication configuration, the reader can generate an RF field that can power a target that does not require batteries. This enables use of an NFC target having a simple form such as a tag, a sticker, a key fob, or a smart card. Simple NFC targets are typically read-only and directed to a single application, for example, a single-purpose contactless smart card used for payment in connection with a credit card account. In addition to payment, NFC targets have found use in application areas such as ticketing, access, RF identification (RFID) tags, loyalty programs, and coupons.
In a more sophisticated NFC communication configuration, a secure element (SE) installed in a “host” device, such as a mobile phone, can emulate an NFC target. An SE is a tamper-resistant hardware platform, capable of securely running SE applications and storing confidential and cryptographic data. An SE can be included in the subscriber identity module (SIM) or universal integrated circuit card (UICC) of a mobile device (the host) as an embedded SE (eSE). An SE can also by installed in a secure digital (SD) card that can be inserted in to a mobile device. An NFC controller in the mobile device handles communication between the SE and an NFC reader. Such an arrangement allows the SE to emulate a smart card.
Host-based card emulation (HCE), more often simply “Host Card Emulation,” is a technology that allows an NFC-enabled host device, such as a mobile phone, to appear as an NFC target to an NFC reader, without relying on a conventional passive NFC target or an SE. In a typical HCE implementation, the NFC controller, also referred to as a contactless front end (CLF), can interface with an application running under the operating system (OS) of the host. For example, a mobile phone can run a mobile wallet payment application under the phone's OS. The mobile wallet payment application can communicate with an NFC-enabled point of sale (POS) device via the CLF.
Whether using an SE or HCE, operating multiple contactless NFC-enabled applications on a single target device presents several challenges, including the selection of which application to run in a given context in response to interrogation of the target device by a reader. One way to accomplish such selection is by use of an NFC application identifier (AID). The target device maintains a routing table that lists AIDs for the applications on the device, typically in the NFC controller. When the target device receives a request to select an application (“SELECT AID” command using an AID as an argument) from a reader, the target device searches for the AID in its routing table.
A typical AID includes up to sixteen 8-bit bytes. Bits 8 to 5 of the first byte indicate a category from among “international,” “national,” “standard,” and “proprietary.” Both the international and national AID format allocate the first five (5) bytes to a “registered application provider identifier,” and up to an additional eleven (11) bytes to a proprietary application identifier extension. For a standard category AID, the first byte is set to “E8.” An object identifier follows for identifying a standard specifying an application. An application identifier extension (specified according to the identified standard) may follow for identifying different implementations. A proprietary AID includes up to sixteen (16) bytes, with bits 8 to 5 of the first byte set to “F.” In the proprietary category, as application providers are not registered, different application providers may use the same AID.
In the NFC payment application area, an additional feature exists to allow an NFC reader to determine which NFC-enabled payment applications are available on a target device brought into proximity with the reader. The Proximity Payment System Environment (PPSE) is an applet that may execute on the target device and may be used by the reader to determine which of the active applications on a target device should be used for payment. The PPSE collects data on each NFC-enabled payment application executing on the target device, and forms a SELECT PPSE RESPONSE. The SELECT PPSE RESPONSE contains the AID for each payment application that the target device may make available to an NFC reader. The SELECT PPSE RESPONSE also may contain name, preference, and option information related to the payment applications that the target device might make available to the NFC reader. For example, the PPSE SELECT RESPONSE may contain various type length value (TLV) structures including file control information (FCI) Template and FCI proprietary template arranged in an industry defined format.
When the NFC reader first detects the proximity of the target device, the NFC reader issues a SELECT PPSE command to the target device. The PPSE responds to the SELECT PPSE command with the SELECT PPSE RESPONSE. Based on the SELECT PPSE RESPONSE and optional further interaction between the POS Device, the NFC target, and the user, a transaction with a specific payment option compatible with both the POS device and the NFC target can be completed.